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Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1998). All Rights Reserved. 
Overview 


This document describes a general syntax for data that may have 
cryptography applied to it, such as digital signatures and digital 
envelopes. The syntax admits recursion, so that, for example, one 
envelope can be nested inside another, or one party can sign some 
previously enveloped digital data. It also allows arbitrary 
attributes, such as signing time, to be authenticated along with the 
content of a message, and provides for other attributes such as 
countersignatures to be associated with a signature. A degenerate 
case of the syntax provides a means for disseminating certificates 
and certificate-revocation lists. 


1. Scope 


This document is compatible with Privacy-Enhanced Mail (PEM) in that 
signed-data and signed-and-enveloped-data content, constructed ina 
PEM-compatible mode, can be converted into PEM messages without any 
cryptographic operations. PEM messages can similarly be converted 
into the signed-data and signed-and-enveloped data content types. 


This document can support a variety of architectures for 
certificate-based key management, such as the one proposed for 
Privacy-Enhanced Mail in RFC 1422. Architectural decisions such as 
what certificate issuers are considered "top-level," what entities 
certificate issuers are authorized to certify, what distinguished 
names are considered acceptable, and what policies certificate 
issuers must follow (such as signing only with secure hardware, or 
requiring entities to present specific forms of identification) are 
left outside the document. 
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The values produced according to this document are intended to be 
BER-encoded, which means that the values would typically be 
represented as octet strings. While many systems are capable of 
transmitting arbitrary octet strings reliably, it is well known that 
many electronic-mail systems are not. This document does not address 
mechanisms for encoding octet strings as (say) strings of ASCII 
characters or other techniques for enabling reliable transmission by 
re-encoding the octet string. RFC 1421 suggests one possible solution 
to this problem. 
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For the purposes of this document, 
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and associated parameters. 
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ASN.1: Abstract Syntax Notation One, as defined in X.208. 


Attribute: A type that contains an attribute type 
object identifier) and one or more attribute values. This type is 


defined in X.501. 


BER: Basic Encoding Rules, as defined in X.209. 


Kaliski 


(specified by 


1998 


the following definitions apply. 


(by object 
This type is defined in X.509. 
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Certificate: A type that binds an entity’s distinguished name to a 
public key with a digital signature. This type is defined in X.509. 
This type also contains the distinguished name of the certificate 
issuer (the signer), an issuer-specific serial number, the issuer’s 
Signature algorithm identifier, and a validity period. 


CertificateSerialNumber: A type that uniquely identifies a 
certificate (and thereby an entity and a public key) among those 
signed by a particular certificate issuer. This type is defined in 
X.509. 


CertificateRevocationList: A type that contains information about 
certificates whose validity an issuer has prematurely revoked. The 
information consists of an issuer name, the time of issue, the next 
scheduled time of issue, and a list of certificate serial numbers and 
their associated revocation times. The CRL is signed by the issuer. 
The type intended by this document is the one defined RFC 1422. 


DER: Distinguished Encoding Rules for ASN.1, as defined in X.509, 
Section 8.7. 


DES: Data Encryption Standard, as defined in FIPS PUB 46-1. 


desCBC: The object identifier for DES in cipher-block chaining (CBC) 
mode, as defined in [NIST91]. 


ExtendedCertificate: A type that consists of an X.509 public-key 
certificate and a set of attributes, collectively signed by the 
issuer of the X.509 public-key certificate. This type is defined in 
PKCS #6. 


MD2: RSA Data Security, Inc.’s MD2 message-digest algorithm, as 
defined in RFC 1319. 


md2: The object identifier for MD2, as defined in RFC 1319. 


MD5: RSA Data Security, Inc.’s MD5 message-digest algorithm, as 
defined in RFC 1321. 


md5: The object identifier for MD5, as defined in RFC 1321. 


Name: A type that uniquely identifies or "distinguishes" objects in 
an X.500 directory. This type is defined in X.501. In an X.509 
certificate, the type identifies the certificate issuer and the 
entity whose public key is certified. 


PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424. 
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RSA: The RSA public-key cryptosystem, as defined in [RSA78]. 


rsaEncryption: The object identifier for RSA encryption, as defined 
in PKCS #1. 


4. Symbols and abbreviations 
No symbols or abbreviations are defined in this document. 
5. General overview 


The following nine sections specify useful types, general syntax, six 
content types, and object identifiers. 


The syntax is general enough to support many different content types. 
This document defines six: data, signed data, enveloped data, 
signed-and-enveloped data, digested data, and encrypted data. Other 
content types may be added in the future. The use of content types 
defined outside this document is possible, but is subject to 
bilateral agreement between parties exchanging content. 


This document exports one type, ContentInfo, as well as the various 
object identifiers. 


There are two classes of content types: base and enhanced. Content 
types in the base class contain "just data," with no cryptographic 
enhancements. Presently, one content type is in this class, the data 
content type. Content types in the enhanced class contain content of 
some type (possibly encrypted), and other cryptographic enhancements. 
For example, enveloped-data content can contain (encrypted) signed- 
data content, which can contain data content. The four non-data 
content types fall into the enhanced class. The content types in the 
enhanced class thus employ encapsulation, giving rise to the terms 
"outer" content (the one containing the enhancements) and "inner" 
content (the one being enhanced). 


The document is designed such that the enhanced content types can be 
prepared in a single pass using indefinite-length BER encoding, and 
processed in a single pass in any BER encoding. Single-pass operation 
is especially helpful if content is stored on tapes, or is "piped" 
from another process. One of the drawbacks of single-pass operation, 
however, is that it is difficult to output a DER encoding in a single 
pass, since the lengths of the various components may not be known in 
advance. Since DER encoding is required by the signed-data, signed- 
and-enveloped data, and digested-data content types, an extra pass 
may be necessary when a content type other than data is the inner 
content of one of those content types. 
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6. Useful types 


This section defines types that are useful in at least two places in 
the document. 


6.1 CertificateRevocationLists 


The CertificateRevocationLists type gives a set of certificate- 
revocation lists. It is intended that the set contain information 
sufficient to determine whether the certificates with which the set 
is associated are "hot listed," but there may be more certificate- 
revocation lists than necessary, or there may be fewer than 
necessary. 


CertificateRevocationLists ::= 
SET OF CertificateRevocationList 


6.2 ContentEncryptionAlgorithmIdentifier 


The ContentEncryptionAlgorithmIidentifier type identifies a content- 
encryption algorithm such as DES. A content-encryption algorithm 
supports encryption and decryption operations. The encryption 
operation maps an octet string (the message) to another octet string 
(the ciphertext) under control of a content-encryption key. The 
decryption operation is the inverse of the encryption operation. 
Context determines which operation is intended. 


ContentEncryptionAlgorithmIdentifier ::= 
AlgorithmIdentifier 


6.3 DigestAlgorithmIdentifier 


The DigestAlgorithmIdentifier type identifies a message-digest 
algorithm. Examples include MD2 and MD5. A message-digest algorithm 
maps an octet string (the message) to another octet string (the 
message digest). 


DigestAlgorithmIdentifier ::= AlgorithmIdentifier 
6.4 DigestEncryptionAlgorithmIdentifier 


The DigestEncryptionAlgorithmIdentifier type identifies a digest- 
encryption algorithm under which a message digest can be encrypted. 
One example is PKCS #1’s rsaEncryption. A digest-encryption algorithm 
supports encryption and decryption operations. The encryption 
operation maps an octet string (the message digest) to another octet 
-bp string (the encrypted message digest) under control of a digest- 
encryption key. The decryption operation is the inverse of the 
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encryption operation. Context determines which operation is intended. 


DigestEncryptionAlgorithmIdentifier ::= 
AlgorithmIdentifier 


6.5 ExtendedCertificateOrCertificate 


The ExtendedCertificateOrCertificate type gives either a PKCS #6 
extended certificate or an X.509 certificate. This type follows the 
syntax recommended in Section 6 of PKCS #6: 


ExtendedCertificateOrCertificate ::= CHOICE { 
certificate Certificate, -- X.509 


extendedCertificate [0] IMPLICIT ExtendedCertificate } 
6.6 ExtendedCertificatesAndCertificates 


The ExtendedCertificatesAndCertificates type gives a set of extended 
certificates and X.509 certificates. It is intended that the set be 
sufficient to contain chains from a recognized "root" or "top-level 
certification authority" to all of the signers with which the set is 
associated, but there may be more certificates than necessary, or 
there may be fewer than necessary. 


ExtendedCertificatesAndCertificates ::= 
SET OF ExtendedCertificateOrCertificate 


Note. The precise meaning of a "chain" is outside the scope of this 
document. Some applications of this document may impose upper limits 
on the length of a chain; others may enforce certain relationships 
between the subjects and issuers of certificates in a chain. An 
example of such relationships has been proposed for Privacy-Enhanced 
Mail in RFC 1422. 


6.7 IssuerAndSerialNumber 
The IssuerAndSerialNumber type identifies a certificate (and thereby 
an entity and a public key) by the distinguished name of the 
certificate issuer and an issuer-specific certificate serial number. 
IssuerAndSerialNumber ::= SEQUENCE { 


issuer Name, 
serialNumber CertificateSerialNumber } 
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6.8 KeyEncryptionAlgorithmIdentifier 


The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption 
algorithm under which a content-encryption key can be encrypted. One 
example is PKCS #1’s rsaEncryption. A key-encryption algorithm 
supports encryption and decryption operations. The encryption 
operation maps an octet string (the key) to another octet string (the 
encrypted key) under control of a key-encryption key. The decryption 
operation is the inverse of the encryption operation. Context 
determines which operation is intended. 


KeyEncryptionAlgorithmIdentifier ::= 
AlgorithmIdentifier 


6.9 Version 


The Version type gives a syntax version number, for compatibility 
with future revisions of this document. 


Version ::= INTEGER 
7. General syntax 
The general syntax for content exchanged between entities according 


to this document associates a content type with content. The syntax 
shall have ASN.1 type ContentInfo: 


ContentInfo ::= SEQUENCE { 
contentType ContentType, 
content 


[0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } 


ContentType ::= OBJECT IDENTIFIER 


The fields of type ContentInfo have the following meanings: 


(0) contentType indicates the type of content. It is 
an object identifier, which means it is a unique string of 
integers assigned by the authority that defines the content 
type. This document defines six content types (see Section 
14): data, signedData, envelopedData, 
signedAndEnvelopedData, digestedData, and encryptedData. 


fe) content is the content. The field is optional, and 
if the field is not present, its intended value must be 
supplied by other means. Its type is defined along with the 
object identifier for contentType. 
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Notes. 


T; The methods below assume that the type of content 
can be determined uniquely by contentType, so the type 
defined along with the object identifier should not be a 
CHOICE type. 


2 When a ContentInfo value is the inner content of 
signed-data, signed-and-enveloped-data, or digested-data 
content, a message-digest algorithm is applied to the 
contents octets of the DER encoding of the content field. 
When a ContentInfo value is the inner content of 
enveloped-data or signed-and-enveloped-data content, a 
content-encryption algorithm is applied to the contents 
octets of a definite-length BER encoding of the content 
field. 


oe The optional omission of the content field makes 
it possible to construct "external signatures," for 
example, without modification to or replication of the 
content to which the signatures apply. In the case of 
external signatures, the content being signed would be 
omitted from the "inner" encapsulated ContentInfo value 
included in the signed-data content type. 


8. Data content type 


The data content type is just an octet string. It shall have ASN.1 
type Data: 


Data ::= OCTET STRING 


The data content type is intended to refer to arbitrary octet 
strings, such as ASCII text files; the interpretation is left to the 
application. Such strings need not have any internal structure 
(although they may; they could even be DER encodings). 


9. Signed-data content type 


The signed-data content type consists of content of any type and 
encrypted message digests of the content for zero or more signers. 
The encrypted digest for a signer is a "digital signature" on the 
content for that signer. Any type of content can be signed by any 
number of signers in parallel. Furthermore, the syntax has a 
degenerate case in which there are no signers on the content. The 
degenerate case provides a means for disseminating certificates and 
certificate-revocation lists. 
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It is expected that the typical application of the signed-data 
content type will be to represent one signer’s digital signature on 
content of the data content type. Another typical application will be 
to disseminate certificates and certificate-revocation lists. 


The process by which signed data is constructed involves the 
following steps: 


1; For each signer, a message digest is computed on 
the content with a signer-specific message-digest 
algorithm. (If two signers employ the same message-digest 
algorithm, then the message digest need be computed for 
only one of them.) If the signer is authenticating any 
information other than the content (see Section 9.2), the 
message digest of the content and the other information are 
digested with the signer’s message digest algorithm, and 
the result becomes the "message digest." 


2a For each signer, the message digest and associated 
information are encrypted with the signer’s private key. 


3. For each signer, the encrypted message digest and 
other signer-specific information are collected into a 
SignerInfo value, defined in Section 9.2. Certificates and 
certificate-revocation lists for each signer, and those not 
corresponding to any signer, are collected in this step. 


As The message-digest algorithms for all the signers 
and the SignerInfo values for all the signers are collected 
together with the content into a SignedData value, defined 
in Section 9.1. 


A recipient verifies the signatures by decrypting the encrypted 
message digest for each signer with the signer’s public key, then 
comparing the recovered message digest to an independently computed 
message digest. The signer’s public key is either contained in a 
certificate included in the signer information, or is referenced by 
an issuer distinguished name and an issuer-specific serial number 
that uniquely identify the certificate for the public key. 


This section is divided into five parts. The first part describes the 
top-level type SignedData, the second part describes the per-signer 
information type SignerInfo, and the third and fourth parts describe 
the message-digesting and digest-encryption processes. The fifth part 
summarizes compatibility with Privacy-Enhanced Mail. 
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9.1 SignedData type 


The signed-data content type shall have ASN.1 type SignedData: 


SignedData 


::= SEQUENCE { 


version Version, 

digestAlgorithms DigestAlgorithmIdentifiers, 
contentInfo ContentInfo, 

certificates 


crls 


IMPLICIT ExtendedCertificatesAndCertificates 
OPTIONAL, 


IMPLICIT CertificateRevocationLists OPTIONAL, 


signerInfos SignerInfos } 


DigestAlgorithmIdentifiers ::= 


SET OF DigestAlgorithmIdentifier 


SignerInfos ::= SET OF SignerInfo 


The fields of type SignedData have the following meanings: 


Kaliski 


version is the syntax version number. It shall be 
1 for this version of the document. 


digestAlgorithms is a collection of message-digest 
algorithm identifiers. There may be any number of 
elements in the collection, including zero. Each 
element identifies the message-digest algorithm 
(and any associated parameters) under which the 
content is digested for a some signer. The 
collection is intended to list the message-digest 
algorithms employed by all of the signers, in any 
order, to facilitate one-pass signature 
verification. The message-digesting process is 
described in Section 9.3. 


contentInfo is the content that is signed. It can 
have any of the defined content types. 


certificates is a set of PKCS #6 extended 

certificates and X.509 certificates. It is intended that 
the set be sufficient to contain chains from a recognized 
"root" or "top-level certification authority" to all of the 
signers in the signerInfos field. There may be more 
certificates than necessary, and there may be certificates 
sufficient to contain chains from two or more independent 
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top-level certification authorities. There may also be 
fewer certificates than necessary, if it is expected that 
those verifying the signatures have an alternate means of 
obtaining necessary certificates (e.g., from a previous set 
of certificates). 


fe) crls is a set of certificate-revocation lists. It 
is intended that the set contain information sufficient to 
determine whether or not the certificates in the 
certificates field are "hot listed," but such 
correspondence is not necessary. There may be more 
certificate-revocation lists than necessary, and there may 
also be fewer certificate-revocation lists than necessary. 


o signerInfos is a collection of per-signer 
information. There may be any number of elements in the 
collection, including zero. 


Notes. 


T; The fact that the digestAlgorithms field comes 
before the contentInfo field and the signerInfos field 
comes after it makes it possible to process a SignedData 
value in a single pass. (Single-pass processing is 
described in Section 5.) 


2s The differences between version 1 SignedData and 
version 0 SignedData (defined in PKCS #7, Version 1.4) are 
the following: 


fe) the digestAlgorithms and signerInfos 
fields may contain zero elements in version 1, 
but not in version 0 


fe) the crls field is allowed in version 1, 
but not in version 0 


Except for the difference in version number, version 0 
SignedData values are acceptable as version 1 values. An 
implementation can therefore process SignedData values of 
either version as though they were version 1 values. It is 
suggested that PKCS implementations generate only version 1 
SignedData values, but be prepared to process SignedData 
values of either version. 


Kaliski Informational [Page 12] 


RFC 2315 


9.2 SignerInf 
Per-signer 


SignerInfo 


PKCS #7: Crytographic Message Syntax March 1998 


In the degenerate case where there are no signers 

on the content, the ContentInfo value being "signed" is 
irrelevant. It is recommended in that case that the content 
type of the ContentInfo value being "Signed" be data, and 
the content field of the ContentInfo value be omitted. 


o type 
information is represented in the type SignerInfo: 


::= SEQUENCE { 


version Version, 
issuerAndSerialNumber IssuerAndSerialNumber, 


digestAl 
authenti 


gorithm DigestAlgorithmIdentifier, 
catedAttributes 


[0] IMPLICIT Attributes OPTIONAL, 
digestEncryptionAlgorithm 


Digest 
encrypte 


EncryptionAlgorithmIidentifier, 
dDigest EncryptedDigest, 


unauthenticatedAttributes 
[1] IMPLICIT Attributes OPTIONAL } 


EncryptedD 
The fields 


(0) 
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igest ::= OCTET STRING 
of type SignerInfo have the following meanings: 


version is the syntax version number. It shall be 
1 for this version of the document. 


issuerAndSerialNumber specifies the signer’s 

certificate (and thereby the signer’s distinguished name 
and public key) by issuer distinguished name and issuer- 
specific serial number. 


digestAlgorithm identifies the message-digest 

algorithm (and any associated parameters) under which the 
content and authenticated attributes (if present) are 
digested. It should be among those in the digestAlgorithms 
field of the superior SignerInfo value. The message- 
digesting process is described in Section 9.3. 


authenticatedAttributes is a set of attributes 

that are signed (i.e., authenticated) by the signer. The 
field is optional, but it must be present if the content 
type of the ContentInfo value being signed is not data. If 
the field is present, it must contain, at a minimum, two 
attributes: 
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T; A PKCS #9 content-type attribute having 
as its value the content type of the 
ContentInfo value being signed. 


2. A PKCS #9 message-digest attribute, 
having as its value the message digest 
of the content (see below). 


Other attribute types that might be useful here, such as 
signing time, are also defined in PKCS #9. 


digestEncryptionAlgorithm identifies the digest- 
encryption algorithm (and any associated parameters) under 
which the message digest and associated information are 
encrypted with the signer’s private key. The digest- 
encryption process is described in Section 9.4. 


encryptedDigest is the result of encrypting the 
message digest and associated information with the signer’s 
private key. 


unauthenticatedAttributes is a set of attributes 

that are not signed (i.e., authenticated) by the signer. 
The field is optional. Attribute types that might be useful 
here, such as countersignatures, are defined in PKCS #9. 


It is recommended in the interest of PEM 

compatibility that the authenticatedAttributes field be 
omitted whenever the content type of the ContentInfo value 
being signed is data and there are no other authenticated 
attributes. 


The difference between version 1 SignerInfo and 

version 0 SignerInfo (defined in PKCS #7, Version 1.4) is 
in the message-digest encryption process (see Section 9.4). 
Only the PEM-compatible processes are different, reflecting 
changes in Privacy-Enhanced Mail signature methods. There 
is no difference in the non-PEM-compatible message-digest 
encryption process. 


It is suggested that PKCS implementations generate only 
version 1 SignedData values. Since the PEM signature method 
with which version 0 is compatible is obsolescent, it is 
suggested that PKCS implementations be prepared to receive 
only version 1 SignedData values. 
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9.3 Message-digesting process 


The message-digesting process computes a message digest on either the 
content being signed or the content together with the signer’s 
authenticated attributes. In either case, the initial input to the 
message-digesting process is the "value" of the content being signed. 
Specifically, the initial input is the contents octets of the DER 
encoding of the content field of the ContentInfo value to which the 
signing process is applied. Only the contents octets of the DER 
encoding of that field are digested, not the identifier octets or the 
length octets. 


The result of the message-digesting process (which is called, 
informally, the "message digest") depends on whether the 
authenticatedAttributes field is present. When the field is absent, 
the result is just the message digest of the content. When the field 
is present, however, the result is the message digest of the complete 
DER encoding of the Attributes value containted in the 
authenticatedAttributes field. (For clarity: The IMPLICIT [0] tag in 
the authenticatedAttributes field is not part of the Attributes 
value. The Attributes value’s tag is SET OF, and the DER encoding of 
the SET OF tag, rather than of the IMPLICIT [0] tag, is to be 
digested along with the length and contents octets of the Attributes 
value.) Since the Attributes value, when the field is present, must 
contain as attributes the content type and the message digest of the 
content, those values are indirectly included in the result. 


When the content being signed has content type data and the 
authenticatedAttributes field is absent, then just the value of the 
data (e.g., the contents of a file) is digested. This has the 
advantage that the length of the content being signed need not be 
known in advance of the encryption process. This method is compatible 
with Privacy-Enhanced Mail. 


Although the identifier octets and the length octets are not 
digested, they are still protected by other means. The length octets 
are protected by the nature of the message-digest algorithm since it 
is by assumption computationally infeasible to find any two distinct 
messages of any length that have the same message digest. 
Furthermore, assuming that the content type uniquely determines the 
identifier octets, the identifier octets are protected implicitly in 
one of two ways: either by the inclusion of the content type in the 
authenticated attributes, or by the use of the PEM-compatible 
alternative in Section 9.4 which implies that the content type is 
data. 
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Note. The fact that the message digest is computed on part of a DER 
encoding does not mean that DER is the required method of 
representing that part for data transfer. Indeed, it is expected that 
some implementations of this document may store objects in other than 
their DER encodings, but such practices do not affect message-digest 
computation. 


9.4 Digest-encryption process 


The input to the digest-encryption process—-the value supplied to the 
signer’s digest-encryption algorithm--includes the result of the 
message-digesting process (informally, the "message digest") and the 
digest algorithm identifier (or object identifier). The result of the 
digest-encryption process is the encryption with the signer’s private 
key of the BER encoding of a value of type DigestInfo: 


DigestInfo ::= SEQUENCE { 
digestAlgorithm DigestAlgorithmIdentifier, 
digest Digest } 


Digest ::= OCTET STRING 
The fields of type DigestInfo have the following meanings: 


o digestAlgorithm identifies the message-digest 
algorithm (and any associated parameters) under which the 
content and authenticated attributes are digested. It 
should be the same as the digestAlgorithm field of the 
superior SignerInfo value. 


(0) digest is the result of the message-digesting 
process. 
Notes. 
ales The only difference between the signature process 


defined here and the signature algorithms defined in PKCS 
#1 is that signatures there are represented as bit strings, 
for consistency with the X.509 SIGNED macro. Here, 
encrypted message digests are octet strings. 


25 The input to the encryption process typically will 
have 30 or fewer octets. If digestEncryptionAlgorithm is 
PKCS #1’s rsaEncryption, then this means that the input can 
be encrypted in a single block as long as the length of the 
RSA modulus is at least 328 bits, which is reasonable and 
consistent with security recommendations. 
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3: A message-digest algorithm identifier is included 
in the DigestInfo value to limit the damage resulting from 
the compromise of one message-digest algorithm. For 
instance, suppose an adversary were able to find messages 
with a given MD2 message digest. That adversary could then 
forge a signature by finding a message with the same MD2 
message digest as one that a signer previously signed, and 
presenting the previous signature as the signature on the 
new message. This attack would succeed only if the signer 
previously used MD2, since the DigestInfo value contains 
the message-digest algorithm. If a signer never trusted 
the MD2 algorithm and always used MD5, then the compromise 
of MD2 would not affect the signer. If the DigestInfo value 
contained only the message digest, however, the compromise 
of MD2 would affect signers that use any message-digest 
algorithm. 


4. There is potential for ambiguity due to the fact 
that the DigestInfo value does not indicate whether the 
digest field contains just the message digest of the 
content or the message digest of the complete DER encoding 
of the authenticatedAttributes field. In other words, it is 
possible for an adversary to transform a signature on 
authenticated attributes to one that appears to be just on 
content by changing the content to be the DER encoding of 
the authenticatedAttributes field, and then removing the 
authenticatedAttributes field. (The reverse transformation 
is possible, but requires that the content be the DER 
encoding of an authenticated attributes value, which is 
unlikely.) This ambiguity is not a new problem, nor is it a 
significant one, as context will generally prevent misuse. 
Indeed, it is also possible for an adversary to transform a 
signature on a certificate or certificate-revocation list 
to one that appears to be just on signed-data content. 


9.5 Compatibility with Privacy-Enhanced Mail 


Compatibility with the MIC-ONLY and MIC-CLEAR process types in PEM 
occurs when the content type of the ContentInfo value being signed is 
data, there are no authenticated attributes, the message-digest 
algorithm is md2 or md5, and the digest-encryption algorithm is PKCS 
#1’s rsaEncryption. Under all those conditions, the encrypted message 
digest produced here matches the one produced in PEM because: 


Ta The value input to the message-digest algorithm in 
PEM is the same as in this document when there are no 
authenticated attributes. MD2 and MD5 in PEM are the same 
as md2 and md5. 
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PA The value encrypted with the signer’s private key 
in PEM (as specified in RFC 1423) is the same as in this 
document when there are no authenticated attributes. RSA 
private-key encryption in PEM is the same as PKCS #1’s 
rsaEncryption. 


The other parts of the signed-data content type (certificates, CRLs, 
algorithm identifiers, etc.) are easily translated to and from their 
corresponding PEM components. 


10. Enveloped-data content type 


The enveloped-data content type consists of encrypted content of any 
type and encrypted content-encryption keys for one or more 
recipients. The combination of encrypted content and encrypted 
content-encryption key for a recipient is a "digital envelope" for 
that recipient. Any type of content can be enveloped for any number 
of recipients in parallel. 


It is expected that the typical application of the enveloped-data 
content type will be to represent one or more recipients’ digital 
envelopes on content of the data, digested-data, or signed-data 
content types. 


The process by which enveloped data is constructed involves the 
following steps: 


T A content-encryption key for a particular content- 
encryption algorithm is generated at random. 


2 For each recipient, the content-encryption key is 
encrypted with the recipient’s public key. 


33 For each recipient, the encrypted content- 
encryption key and other recipient-specific information are 
collected into a RecipientInfo value, defined in Section 
10.2. 


4. The content is encrypted with the content- 
encryption key. (Content encryption may require that the 
content be padded to a multiple of some block size; see 
Section 10.3 for discussion.) 


Sy The RecipientInfo values for all the recipients 


are collected together with the encrypted content into a 
EnvelopedData value, defined in Section 10.1. 
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10. 


A recipient opens the envelope by decrypting the one of the encrypted 
content-encryption keys with the recipient’s private key and 
decrypting the encrypted content with the recovered content- 
encryption key. The recipient’s private key is referenced by an 
issuer distinguished name and an issuer-specific serial number that 
uniquely identify the certificate for the corresponding public key. 


This section is divided into four parts. The first part describes the 
top-level type EnvelopedData, the second part describes the per- 
recipient information type RecipientInfo, and the third and fourth 
parts describe the content-encryption and key-encryption processes. 


This content type is not compatible with Privacy-Enhanced Mail 
(although some processes it defines are compatible with their PEM 
counterparts), since Privacy-Enhanced Mail always involves digital 
signatures, never digital envelopes alone. 


1 EnvelopedData type 
The enveloped-data content type shall have ASN.1 type EnvelopedData: 


EnvelopedData ::= SEQUENCE { 
version Version, 
recipientiInfos RecipientiInfos, 
encryptedContentInfo EncryptedContentiInfo } 


RecipientInfos ::= SET OF RecipientInfo 


EncryptedContentiInfo ::= SEQUENCE { 
contentType ContentType, 
contentEncryptionAlgorithm 

ContentEncryptionAlgorithmIdentifier, 
encryptedContent 
[0] IMPLICIT EncryptedContent OPTIONAL } 


EncryptedContent ::= OCTET STRING 
The fields of type EnvelopedData have the following meanings: 


o version is the syntax version number. It shall be 
0 for this version of the document. 


fe) recipientInfos is a collection of per-recipient 
information. There must be at least one element in 
the collection. 


fe) encryptedContentInfo is the encrypted content 
information. 
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The fields of type EncryptedContentInfo have the following meanings: 
fe) contentType indicates the type of content. 


o contentEncryptionAlgorithm identifies the content- 
encryption algorithm (and any associated 
parameters) under which the content is encrypted. 
The content-encryption process is described in 
Section 10.3. This algorithm is the same for all 
recipients. 


fe) encryptedContent is the result of encrypting the 
content. The field is optional, and if the field 
is not present, its intended value must be 
supplied by other means. 


Note. The fact that the recipientInfos field comes before the 
encryptedContentInfo field makes it possible to process an 
EnvelopedData value in a single pass. (Single-pass processing is 
described in Section 5.) 


10.2 RecipientInfo type 
Per-recipient information is represented in the type RecipientInfo: 
RecipientInfo ::= SEQUENCE { 
version Version, 
issuerAndSerialNumber IssuerAndSerialNumber, 


keyEncryptionAlgorithm 


KeyEncryptionAlgorithmIdentifier, 
encryptedKey EncryptedKey } 


EncryptedKey ::= OCTET STRING 
The fields of type RecipientInfo have the following meanings: 


(0) version is the syntax version number. It shall be 
0 for this version of the document. 


fe) issuerAndSerialNumber specifies the recipient’s 
certificate (and thereby the recipient’s 
distinguished name and public key) by issuer 
distinguished name and issuer-specific serial 
number. 
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fe) keyEncryptionAlgorithm identifies the key- 
encryption algorithm (and any associated 
parameters) under which the content-encryption key 
is encrypted with the recipient’s public key. The 
key-encryption process is described in Section 
10.4. 


(0) encryptedKey is the result of encrypting the 
content-encryption key with the recipient’s public 
key (see below). 


10.3 Content-encryption process 


The input to the content-encryption process is the "value" of the 
content being enveloped. Specifically, the input is the contents 
octets of a definite-length BER encoding of the content field of the 
ContentInfo value to which the enveloping process is applied. Only 
the contents octets of the BER encoding are encrypted, not the 
identifier octets or length octets; those other octets are not 
represented at all. 


When the content being enveloped has content type data, then just the 
value of the data (e.g., the contents of a file) is encrypted. This 
has the advantage that the length of the content being encrypted need 
not be known in advance of the encryption process. This method is 
compatible with Privacy-Enhanced Mail. 


The identifier octets and the length octets are not encrypted. The 
length octets may be protected implicitly by the encryption process, 
depending on the encryption algorithm. The identifier octets are not 
protected at all, although they can be recovered from the content 
type, assuming that the content type uniquely determines the 
identifier octets. Explicit protection of the identifier and length 
octets requires that the signed-and-enveloped-data content type be 
employed, or that the digested-data and enveloped-data content types 
be applied in succession. 


Notes. 


T; The reason that a definite-length BER encoding is 
required is that the bit indicating whether the length is 
definite or indefinite is not recorded anywhere in the 
enveloped-data content type. Definite-length encoding is 
more appropriate for simple types such as octet strings, so 
definite-length encoding is chosen. 
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10. 


Lig 


Dig Some content-encryption algorithms assume the 
input length is a multiple of k octets, where k > 1, and 
let the application define a method for handling inputs 
whose lengths are not a multiple of k octets. For such 
algorithms, the method shall be to pad the input at the 
trailing end with k - (1 mod k) octets all having value k - 
(1 mod k), where 1 is the length of the input. In other 
words, the input is padded at the trailing end with one of 
the following strings: 


01 -- if 1 mod k = k-1 
02 02 -- if 1 mod k = k-2 
kk... kk -- if 1 mod k = 0 


The padding can be removed unambiguously since all input is 
padded and no padding string is a suffix of another. This 
padding method is well-defined if and only if k < 256; 
methods for larger k are an open issue for further study. 


4 Key-encryption process 


The input to the key-encryption process-—-the value supplied to the 
recipient’s key-encryption algorithm--is just the "value" of the 
content-encryption key. 


Signed-and-enveloped-data content type 


This section defines the signed-and-enveloped-data content type. For 
brevity, much of this section is expressed in terms of material in 
Sections 9 and 10. 


The signed-and-enveloped-data content type consists of encrypted 
content of any type, encrypted content-encryption keys for one or 
more recipients, and doubly encrypted message digests for one or more 
signers. The "double encryption" consists of an encryption with a 
signer’s private key followed by an encryption with the content- 
encryption key. 


The combination of encrypted content and encrypted content-encryption 
key for a recipient is a "digital envelope" for that recipient. The 
recovered singly encrypted message digest for a signer is a "digital 
signature" on the recovered content for that signer. Any type of 
content can be enveloped for any number of recipients and signed by 
any number of signers in parallel. 
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It is expected that the typical application of the signed-and- 
enveloped-data content type will be to represent one signer’s digital 
signature and one or more recipients’ digital envelopes on content of 
the data content type. 


The process by which signed-and-enveloped data is constructed 
involves the following steps: 


dis A content-encryption key for a particular content- 
encryption algorithm is generated at random. 


23 For each recipient, the content-encryption key is 
encrypted with the recipient’s public key. 


3: For each recipient, the encrypted content- 
encryption key and other recipient-specific 
information are collected into a RecipientInfo 
value, defined in Section 10.2. 


4. For each signer, a message digest is computed on 
the content with a signer-specific message-digest 
algorithm. (If two signers employ the same message- 
digest algorithm, then the message digest need be 
computed for only one of them.) 


Dis, For each signer, the message digest and associated 
information are encrypted with the signer’s 
private key, and the result is encrypted with the 
content-encryption key. (The second encryption may 
require that the result of the first encryption be 
padded to a multiple of some block size; see 
Section 10.3 for discussion.) 


6. For each signer, the doubly encrypted message 
digest and other signer-specific information are 
collected into a SignerInfo value, defined in 
Section 9.2. 


Ws The content is encrypted with the content- 
encryption key. (See Section 10.3 for discussion.) 
8. The message-digest algorithms for all the signers, 


the SignerInfo values for all the signers and the 
RecipientInfo values for all the recipients are 
collected together with the encrypted content into 
a SignedAndEnvelopedData value, defined in Section 
TAL ds 
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A recipient opens the envelope and verifies the signatures in two 
steps. First, the one of the encrypted content-encryption keys is 
decrypted with the recipient’s private key, and the encrypted content 
is decrypted with the recovered content-encryption key. Second, the 
doubly encrypted message digest for each signer is decrypted with the 
recovered content-encryption key, the result is decrypted with the 
signer’s public key, and the recovered message digest is compared to 
an independently computed message digest. 


Recipient private keys and signer public keys are contained or 
referenced as discussed in Sections 9 and 10. 


This section is divided into three parts. The first part describes 
the top-level type SignedAndEnvelopedData and the second part 
describes the digest-encryption process. Other types and processes 
are the same as in Sections 9 and 10. The third part summarizes 
compatibility with Privacy-Enhanced Mail. 


Note. The signed-and-enveloped-data content type provides 
cryptographic enhancements similar to those resulting from the 
sequential combination of signed-data and enveloped-data content 
types. However, since the signed-and-enveloped-data content type does 
not have authenticated or unauthenticated attributes, nor does it 
provide enveloping of signer information other than the signature, 
the sequential combination of signed-data and enveloped-data content 
types is generally preferable to the SignedAndEnvelopedData content 
type, except when compatibility with the ENCRYPTED process type in 
Privacy-Enhanced Mail in intended. 


11.1 SignedAndEnvelopedData type 


The signed-and-enveloped-data content type shall have ASN.1 type 
SignedAndEnvelopedData: 


SignedAndEnvelopedData ::= SEQUENCE { 
version Version, 
recipientInfos RecipientInfos, 
digestAlgorithms DigestAlgorithmIdentifiers, 
encryptedContentiInfo EncryptedContentiInfo, 
certificates 
[0] IMPLICIT ExtendedCertificatesAndCertificates 
OPTIONAL, 


crls 
[1] IMPLICIT CertificateRevocationLists OPTIONAL, 
signerInfos SignerInfos } 
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The fields of type SignedAndEnvelopedData have the following 
meanings: 


(0) version is the syntax version number. It shall be 
1 for this version of the document. 


o recipientInfos is a collection of per-recipient 
information, as in Section 10. There must be at 
least one element in the collection. 


fe) digestAlgorithms is a collection of message-digest 
algorithm identifiers, as in Section 9. The 
message-digesting process is the same as in 
Section 9 in the case when there are no 
authenticated attributes. 


fe) encryptedContentInfo is the encrypted content, as 
in Section 10. It can have any of the defined 
content types. 


fe) certificates is a set of PKCS #6 extended 
certificates and X.509 certificates, as in Section 
9. 


o crls is a set of certificate-revocation lists, as 
in Section 9. 


fe) signerInfos is a collection of per-signer 
information. There must be at least one element in 
the collection. SignerInfo values have the same 
meaning as in Section 9 with the exception of the 
encryptedDigest field (see below). 


Notes. 


I; The fact that the recipientInfos and 
digestAlgorithms fields come before the contentInfo field 
and the signerInfos field comes after it makes it possible 
to process a SignedAndEnvelopedData value in a single pass. 
(Single-pass processing is described in Section 5.) 


2a The difference between version 1 
SignedAndEnvelopedData and version 0 SignedAndEnvelopedData 
(defined in PKCS #7, Version 1.4) is that the crls field is 
allowed in version 1, but not in version 0. Except for the 
difference in version number, version 0 
SignedAndEnvelopedData values are acceptable as version 1 
values. An implementation can therefore process 
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SignedAndEnvelopedData values of either version as though 
they were version 1 values. It is suggested that PKCS 
implementations generate only version 1 
SignedAndEnvelopedData values, but be prepared to process 
SignedAndEnvelopedData values of either version. 


2 Digest-encryption process 


The input to the digest-encryption process is the same as in Section 
9, but the process itself is different. Specifically, the process 
involves two steps. First, the input to the process is supplied to 
the signer’s digest-encryption algorithm, as in Section 9. Second, 
the result of the first step is encrypted with the content-encryption 
key. There is no DER encoding between the two steps; the "value" 
output by the first step is input directly to the second step. (See 
Section 10.3 for discussion.) 


This process is compatible with the ENCRYPTED process type in 
Privacy-Enhanced Mail. 


Note. The purpose of the second step is to prevent an adversary from 


recovering the message digest of the content. Otherwise, an 
adversary would be able to determine which of a list of candidate 
contents (e.g., "Yes" or "No") is the actual content by comparing the 


their message digests to the actual message digest. 


.3 Compatibility with Privacy-Enhanced Mail 


Compatibility with the ENCRYPTED process type of PEM occurs when the 
content type of the ContentInfo value being signed and enveloped is 
data, the message-digest algorithm is md2 or md5, the content- 
encryption algorithm is DES in CBC mode, the digest-encryption 
algorithm is PKCS #1’s rsaEncryption, and the key-encryption 
algorithm is PKCS #1’s rsaEncryption. Under all those conditions, 
the doubly encrypted message digest and the encrypted content 
encryption key match the ones produced in PEM because of reasons 
similar to those given in Section 9.5, as well as the following: 


F; The value input to the content-encryption 
algorithm in PEM is the same as in this document. 
DES in CBC mode is the same as desCBC. 


2 The value input to the key-encryption algorithm in 
PEM is the same as in this document (see Section 
10.4). RSA public-key encryption in PEM is the 
same as PKCS #1’s rsaEncryption. 
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Ju The double-encryption process applied to the 
message digest in this document and in PEM are the 
same. 


The other parts of the signed-and-enveloped-data content type 
(certificates, CRLs, algorithm identifiers, etc.) are easily 
translated to and from their corresponding PEM components. (CRLs are 
carried in a separate PEM message.) 


12. Digested-data content type 


The digested-data content type consists of content of any type and a 
message digest of the content. 


It is expected that the typical application of the digested-data 
content type will be to add integrity to content of the data content 
type, and that the result would become the content input to the 
enveloped-data content type. 


The process by which digested-data is constructed involves the 
following steps: 


I; A message digest is computed on the content with a 
message-digest algorithm. 


Die The message-digest algorithm and the message 
digest are collected together with the content 
into a DigestedData value. 


A recipient verifies the message digest by comparing the message 
digest to an independently computed message digest. 


The digested-data content type shall have ASN.1 type DigestedData: 
DigestedData ::= SEQUENCE { 
version Version, 
digestAlgorithm DigestAlgorithmIdentifier, 
contentInfo ContentInfo, 
digest Digest } 
Digest ::= OCTET STRING 
The fields of type DigestedData have the following meanings: 


o version is the syntax version number. It shall be 
0 for this version of the document. 
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(0) digestAlgorithm identifies the message-digest 
algorithm (and any associated parameters) under which the 
content is digested. (The message-digesting process is the 
same as in Section 9 in the case when there are no 
authenticated attributes.) 


fe) contentInfo is the content that is digested. It 
can have any of the defined content types. 


o digest is the result of the message-digesting process. 


Note. The fact that the digestAlgorithm field comes before the 
contentInfo field and the digest field comes after it makes it 
possible to process a DigestedData value in a single pass. (Single- 
pass processing is described in Section 5.) 


13. Encrypted-data content type 


The encrypted-data content type consists of encrypted content of any 
type. Unlike the enveloped-data content type, the encrypted-data 
content type has neither recipients nor encrypted content-encryption 
keys. Keys are assumed to be managed by other means. 


It is expected that the typical application of the encrypted-data 
content type will be to encrypt content of the data content type for 
local storage, perhaps where the encryption key is a password. 
The encrypted-data content type shall have ASN.1 type EncryptedData: 
EncryptedData ::= SEQUENCE { 

version Version, 

encryptedContentInfo EncryptedContentInfo } 
The fields of type EncryptedData have the following meanings: 


(0) version is the syntax version number. It shall be 
0 for this version of the document. 


fe) encryptedContentInfo is the encrypted content 
information, as in Section 10. 


14. Object identifiers 
This document defines seven object identifiers: pkcs-7, data, 


signedData, envelopedData, signedAndEnvelopedData, digestedData, and 
encryptedData. 
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The object identifier pkcs-7 identifies this document. 


pkcs-7 OBJECT IDENTIFIER ::= 
{ iso(1) member-body(2) US(840) rsadsi (113549) 
pkcs (1) 7 } 


The object identifiers data, signedData, envelopedData, 
signedAndEnvelopedData, digestedData, and encryptedData, identify, 
respectively, the data, signed-data, enveloped-data, signed-and- 
enveloped-data, digested-data, and encrypted-data content types 
defined in Sections 8-13. 


data OBJECT IDENTIFIER ::= { pkcs-7 1 } 
signedData OBJECT IDENTIFIER ::= { pkcs-7 2 } 
envelopedData OBJECT IDENTIFIER ::= { pkcs-7 3 } 


signedAndEnvelopedData OBJECT IDENTIFIER ::= 

{ pkcs-7 4 } 
digestedData OBJECT IDENTIFIER ::= { pkcs-7 5 } 
encryptedData OBJECT IDENTIFIER ::= { pkcs-7 6 } 


These object identifiers are intended to be used in the contentType 
field of a value of type ContentInfo (see Section 5). The content 
field of that type, which has the content-type-specific syntax ANY 
DEFINED BY contentType, would have ASN.1 type Data, SignedData, 
EnvelopedData, SignedAndEnvelopedData, DigestedData, and 
EncryptedData, respectively. These object identifiers are also 
intended to be used in a PKCS #9 content-type attribute. 


Security Considerations 
Security issues are discussed throughout this memo. 


Revision history 


Versions 1.0-1.3 

Versions 1.0-1.3 were distributed to participants in RSA Data 
Security, Inc.’s Public-Key Cryptography Standards meetings in 
February and March 1991. 

Version 1.4 

Version 1.4 is part of the June 3, 1991 initial public release of 


PKCS. Version 1.4 was published as NIST/OSI Implementors’ Workshop 
document SEC-SIG-91-22. 
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Version 1.5 


Version 1.5 incorporates several editorial changes, including updates 
to the references and the addition of a revision history. The 
following substantive changes were made: 


(0) Section 6: CertificateRevocationLists type is 
added. 
fe) Section 9.1: SignedData syntax is revised. The new 


version allows for the dissemination of 
certificate-revocation lists along with 
signatures. It also allows for the dissemination 
of certificates and certificate-revocation lists 
alone, without any signatures. 


fe) Section 9.2: SignerInfo syntax is revised. The new 
version includes a message-digest encryption 
process compatible with Privacy-Enhanced Mail as 
specified in RFC 1423. 


o Section 9.3: Meaning of "the DER encoding of the 
authenticatedAttributes field" is clarified as 
"the DER encoding of the Attributes value." 


fe) Section 10.3: Padding method for content- 
encryption algorithms is described. 


(0) Section 11.1: SignedAndEnvelopedData syntax is 
revised. The new version allows for the 
dissemination of certificate-revocation lists. 


fe) Section 13: Encrypted-data content type is added. 
This content type consists of encrypted content of 
any type. 

fe) Section 14: encryptedData object identifier is 
added. 


Supersedes June 3, 1991 version, which was also published as NIST/OSI 
Implementors’ Workshop document SEC-SIG-91-22. 


Kaliski Informational [Page 30] 


RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 


Acknowledgements 


This document is based on a contribution of RSA Laboratories, a 
division of RSA Data Security, Inc. Any substantial use of the text 
from this document must acknowledge RSA Data Security, Inc. RSA Data 
Security, Inc. requests that all material mentioning or referencing 
this document identify this as "RSA Data Security, Inc. PKCS #7". 


Author’s Address 
Burt Kaliski 
RSA Laboratories East 
20 Crosby Drive 
Bedford, MA 01730 


Phone: (617) 687-7000 
EMail: burt@rsa.com 


Kaliski Informational [Page 31] 


RFC 2315 PKCS #7: Crytographic Message Syntax March 1998 


Full Copyright Statement 
Copyright (C) The Internet Society (1998). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Kaliski Informational [Page 32] 


